In a client/server system architecture, a client entity receives services from a server entity. For example, a telephone receives call-connection and feature services from a telephony switch. For reliability purposes, the server may be replicated, so that if one copy of the server fails, another copy can take over and continue to provide the services to the impacted clients. This is commonly referred to as redundancy and fail-over, respectively.
Modern communications systems generally require failover to a redundant server to be effected by the client, as opposed to the server performing the failover for the client. A client must communicatively connect to and register itself with the server in order to receive services from that server. That means that in order to fail-over form a failed server to a redundant server, the client will have to have been registered with both, either alternatively or simultaneously.
In alternate registration, a client is provided with a list of servers that it may use, and it registers with only one of those servers at a time and obtains services therefrom. If and when that server fails, then the client registers with another server and obtains services from this other server. If and when the second server fails, then the client registers with a third server and obtains services from the third server. And so on. Because registration takes some time, alternate registration results in a delay in the client obtaining a service each time that the client fails over to another server.
In simultaneous registration, a client is provided with a list of servers that it may use, and it registers with all of those servers at once. The client obtains its service from one of these servers at any one time, and if that server fails, the client is poised to immediately start receiving service from one of the other servers. This requires the client to create ad maintain connections to all of the servers all at once. This is a waste of communications network resources, because only one of those connections is used at any one time.
One environment in which these issues arise is a Session Initiation Protocol (SIP) survivable network. Session Initiation Protocol (SIP) is an open signaling protocol for establishing many kinds of real-time communication sessions. Examples of the types of communication sessions that may be established using SIP include voice, video, games, applications, and/or instant messaging. These communication sessions may be carried out on any type of communication device such as a personal computer, laptop computer, Personal Digital Assistant (PDA), cellular phone, IM client, IP phone, traditional telephone, server applications, aggregates of applications, desktop applications, and so on.
A feature of SIP is its ability to use an Address of Record (AOR) as a single unifying public address for all communications to end-users, applications, and service provider networks. Thus, in a world of SIP-enhanced communications, a user's AOR becomes their single address that links the user to all of the communication devices associated with the user. Using this AOR, a caller can reach any one of the user's communication devices, also referred to as User Agents (UAs) without having to know each of the unique device addresses or phone numbers.
Many SIP application servers exist for the purposes of enabling communications applications in a SIP environment and for serving as outbound proxies for a UA, thereby allowing complex networks to be built while hiding that complexity through proxies that devices use to connect into the network. One of the principle areas for such communications applications is call control of a SIP UA. Solutions to the problem of providing a survivable SIP network configuration include the use of SIP proxies that are employed when there is no response to SIP signaling. The proxy can be used to route the signaling via one or more alternate routes in the network. The use of a separate proxy can become expensive since an additional network element other than the call controller or a gateway is required to provide survivability.
Other network server products provide geo-redundant configurations, such that the gateway is unlikely to encounter a network server failure due to the high availability of the network server. Like the use of proxies, this particular solution is relatively expensive since high availability servers need to be purchased and distributed throughout a network. Additional shortcomings of known current solutions include the fact that the network element (e.g., gateway) is not allowed to use an alternate path if the primary SIP signaling path is unavailable; such solutions require hot standby configurations with replication of data across servers; and they require primary and secondary call controllers to use exactly the same version of SIP and provide exactly the same set of SIP features to SIP endpoints.
The logic to determine when a network failure has occurred has been traditionally placed in routers, which have the ability to check the IP layer of the network to determine if various network elements are operating properly. This failure/failback detection logic has been placed in the router to relieve the processing burden on the rest of the network components. One major shortcoming to this particular configuration is that the routers are unable to detect at the SIP application level whether a server or other network element is operational. There may be many instances when a server is operational at the IP layer level but the SIP controller is not operational. Routers and other network elements of the prior art heretofore have been unable in these situations to identify such failure conditions and would register such a server as operational. Consequently, it has been proposed to place the failure-determining logic in the Session Initiation Protocol (SIP) enabled communication endpoint and to enable the SIP endpoint to effect either alternate registration or simultaneous registration with the SIP controllers.